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Abstract. From the point of view of large information systems designers 
the most important thing is a certain abstraction enabling integration of 
heterogeneous solutions. Abstraction is associated with the standardization 
of protocols and interfaces of appropriate services. Behind this fagade any 
device or sensor system may be hidden, even humans recording their 
measurements. This study presents selected topics and details related to 
two families of standards developed byOGC: OpenLS and SWE. It also dis- 
cusses the technical details of a solution built to intercept radio messages 
broadcast in the APRS network with telemetric information and weather 
conditions as payload. The basic assumptions and objectives of a prototype 
system that i ntegrates elements of the APRS network and SWE are given. 
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1. Introduction 

Modern measuring devices are no longer seen as tools for qualitative and 
quantitative measurements only. They have become parts of highly special- 
ized solutions, used for data acquisition and post- processing, offering 
hardware and software i nterfaces for communication. I n the construction of 
these solutions the latest technologies from various fields are employed, 
including optics, precision mechanics, satellite and information technolo- 
gies. Thanks to the Internet and mobile technologies, several architectural 
and communication barriers caused by the wiring and placement of the 
sensors have been broken. Only recently the LBS (Location-Based Services) 
entered the field of IT. These are information services, available from mo- 
bile devices via mobile networks, giving possibility of utilization of a mobile 
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device location (Virrantausetal., 200]), or are deployed at sites that use the 
position of mobile devices for their offers (OGC, 2008). LBS can be placed 
at the intersection of three areas: ICT (information and communication 
technology), Internet and geoinformatics. Underlying standards allow, 
among others, to solve some issues related to the implementation of some 
business processes, including authorization, authentication, reporting and 
billing. 

Accessing sensors through web services, their control and data acquisition 
attracted attention of the OGC (Open Geospatial Consortium). The open 
standards developed in the scope of the OGC SWE (Sensor Web Enable- 
ment) framework paved the way to the i ntegrati on of different sensory sys- 
tems in a platform- independent and service- oriented architecture. They are 
recognized as common tools used in the SDI (Spatial Data I nfrastructure) 
i mpl ementati on, where geospati al i nformati on pi ays a key rol e. 

I n addition to LBS and SWE, an excellent source of information about the 
current state of the environment is the amateur radio network (Dabrowski 
K, 1994). In the 70-ies of the last century, the amprnet (Amateur Packet 
Radio Network) was created, for which IPv4 subnet 44.0.0.0/8 was re- 
served. The APRS (Automatic Packet Reporting System) is a branch of this 
network. Its primary use is to provide telemetry information about objects 
on the network (including location), or to distribute information from vari- 
ous sensors (eg. weather stations). Thus, the network is particularly useful 
in emergency situations (Lehman JJ , 2003). Based on the APRS the APRS 
IS (APRS Internet System) was created. It is a Internet- based network, 
connecting APRS radio networks around the world. It allows to store 
broadcast data for later processing and retransmission. Currently, the APRS 
IS consists of several Tier servers, which can communicate with individual 
customers, and Tier2 servers, on ports of which arbitrary data filtering can 
be done. A special role in the APRS network is played by the I Gates (Inter- 
net Gates) - the gateways enabling transmission of data received on the air 
locally to the servers managing the data and allowing their distribution to 
other stations. 

In this paper the principles and selected details of two families of the 
OpenLS and SWE OGC standards are described. Their potentials are re- 
viewed and the assumptions are stated of an implementation of a prototype 
system for environ mental -related data acquisition from various sources. 
The technical details connected with the interception of radio messages 
from the APRS network and passing them on are discussed. Finally, the 
integration of the APRS network (with weather stations linked in) with the 
SDI trough the SWE service implementation is proposed and elements of a 
prototype are presented. 



2. Technology 



2.1. SWE 

The core of the SWE version 10 specification includes: theO&M (Observa- 
tions & Measurements Schema), theSensorML (Sensor Model Language), 
theTML orTransducerML (Transducer Markup Language), the SOS (Sen- 
sor Observations Service), the SPS (Sensor Planning Service), the SAS 
(Sensor Alert Service), and theWNS (Web Notification Services). The SWE 
specifications are updated and harmonized with other OGC standards for 
geospatial processing. The last upgrade to version 2.0 caused a withdrawal 
of theTM L specification and publishing of some new documents: the SWE 
Common Data Model Encoding Standard, and the SWE Service Model Im- 
plementation Standard. 

The SWE standards provide rules that enable an implementation of net- 
work services independently from the supported platforms and the man- 
aged sensors systems. In particular, the SOS specification (OGC, 2012) de- 
fines a protocol and an interface of a service that allow exchanging data 
between users and sensor systems running in a synchronous or asynchro- 
nous mode, loosely or tightly coupled with the server. Using this protocol it 
is possible to publish and request sensor readings using the HTTP protocol. 
The specification (OGC, 2006) defines four profiles of an SOS service: core, 
transactional, and entire. All operations defined in the basic profile are 
mandatory. Each SOS service must support them. Operations defined in the 
other prof i I es are opti onal . 

2.2. LBS 

Communication in the LBS is bi-directional: the user provides information 
about his/her location and interests (i.e. context), and the service responds 
with information tailored to the needs (the result). To enable easy imple- 
mentation and integration of different location- based services, the OGC 
developed theOpenLS (Open Location Services) specification (OGC, 2008). 
This specification is closely related to other commonly used standards and 
provides the definitions of five basic services (OpenLS Core Services) along 
with the descriptions of their interfaces, and theADT (Abstract Data Type) 
and information models used (OpenLS I nformation Model). The basic ser- 
vices include: 

• Directory Service, 

• Gateway Service, 

• Location Utility Service (Geocoder/ReverseGeocoder), 



• Presentation Service - for geographical information rendering on 
layered maps accordi ng to the ADT used, 

• Route Service - for defining/ retrieving route information that 
meets defined criteria (an enriched version of this service is the 
Navigation Service, supporting additional navigation parameters 
required for route rendering, cost evaluation etc.). 

All these services are usually offered by the GeoMobility Server - an appli- 
cation that interacts with clients in an automatic manner. In the common 
scheme a cl i ent sends a query vi a a wi rel ess network ( F i gure 1) . The query i s 
captured by the Service Platform and, after running some obligatory steps 
(authentication, payment, etc.), it is passed to the GeoMobility Server as a 
proper OpenLS request. The server determines the location of the client 
devi ce vi a a gateway, usi ng the GM LC/ M PC (and a network of broadcasti ng 
stations). Optionally, the client's device itself provides information about its 
location using the built-in GPS. When the location data reach the GeoMo- 
bility Server they are processed and the expected response is prepared. This 
response is transferred through the Service Platform and the wireless net- 
work back to the customer. 



Third party 
services 




Figure L Common scheme of handling of client requests by the GeoMobility Serv- 
er (OGC, 2008). 



2.3. APRS 



The APRS is based on the idea of a Packet Radio Network. However, in 
APRS the one-to-one communication scheme was abandoned in favor of 
one-to-many in order to improve the propagation of messages to multiple 
stations simultaneously. This also significantly simplified the issues related 
to the topology of the network and addressing. The broadcast messages - 
including both location and telemetry data (Bragg, 201]), and metadata 
with additional description - are available to all network users. Thanks to 
that, each user can keep track of the current tactical situation in the net- 
work. This is especially useful in emergency situations. The APRS has 
gained great popularity and now covers the whole of Europe and North 
America, and parts of Asia. Network coverage is limited mainly due to the 
use of the VHF band. The normal communication range is tens of kilome- 
ters. Using digital repeater sites located at higher elevations this can be ex- 
tended up to around 200 km. The APRS can also use the shortwave band, 
for which the communication range may vary from of a few hundred to a 
few thousand kilometers. Unfortunately, because of the interference, 
transmission speed is limited up to 300 baud. Therefore, the use of the 
APRS in the shortwave band is limited only to the position reporting. 




Figure 2. APRS activity for the area of the Gulf of Gdansk and Gdansk city (active 
map grabbed from aprs.fi service). 



I n the recent years the possibility of using the satellite technology gained 
popularity (S Ford, 2006). Amateur radio stations have now the ability to 
use the amateur satellite communications in the scope of the projects car- 
ried out by universities and space agencies. Launching the ISS (Interna- 
tional Space Station) opened up possibilities of communication via an 
APRS digital repeater installed on its board. ISS has been assigned the 
unique identifier of RSOI SS-4 and the frequency 145.825M Hz. 

The data exchanged in the APRS might be exposed to the I nternet through 

1 Gates. Thanks to them it is possible to observe the current traffic on com- 
puter screens. For example, to see the traffic on the server po- 
Iand.aprs2.net:14579 one can open a web page under the following link: 
http://www.aprs.pl/live.htm. There also exist a few websites with search ca- 
pabilities for individual stations, such as aprs.fi or jFindU. They offer other 
functions, I ike creation of charts, tables, maps, packet col lections etc. Figure 

2 shows an example of web service output that renders a map with various 
sensor readings broadcast in theAPRS network. 



3. System proposal 
3.1. Assumptions 

Looking at different solutions, a combination of LBS, SWE and APRS based 
applications appears particularly interesting. This alliance opens broad 
range of possibilities of data with spatial references integration (reflecting 
the characteristics of a phenomenon, acquired from the distributed sensor 
systems or created with the participation of users) and services integration 
(tailored to the user needs, offered by commercial companies, social organi- 
zations and other service providers). I n order to check the range of features 
rising from the LBS (more precisely: OpenLS), SWE (specifically SOS) and 
APRS integration, a construction of a prototype system has been planned 
with the foil owing assumptions: 

• the system wi 1 1 use the SOS servi ce as an i nterface for data retri evi ng; 

• the system will be fed with data from weather stations broadcast in the 
APRS network (the data will be captured by the radio receiver and in- 
serted into a database attached to the SOS with the use of dedicated 
software designed for that purpose); 

• the system will allow data insertion through transactions with mobile 
devices equipped with sensors (by sending measurements by dedicated 
software) or assisted by users (who manually enter their observations 
with the aid of dedicated software); 



• the system wi 1 1 offer an OpenLS compl i ant servi ce; 

• the prototype operation will involve the use of weather information for 
specific purpose (eg. planning trips) and the use of mapping compo- 
nents. 

3.2. Available tools 

Thanks to the SOS standard openness several implementations of servers 
and clients compliant were developed and published. An example is the 
open-source OX-Framework (OWS Access Framework) designed by 
52°North (52North, 2012). It includes a ready-made implementation of the 
SOS. Distributed stable binaries are version 3.2.0, but developer version is 
already at 3.5.0. Version 3.5.0 is compatible with the SOS 10.0 specifica- 
tion, and has: 

• all compulsory operations of the basic profile: GetCapabilities, 
GetObservation (O&M encoding), DescribeSensor (SensorML encod- 
ing), 

• the foil owing transactional operations: RegisterSensor, I nsertObserva- 
tion and 

• additional operations: GetFeatureOfl nterest - to obtain a GM L encoded 
representation of features/ objects, GetResult- to pool periodically sen- 
sors data. 

This version also supports selected operations from the SOS 2.0 specifica- 
tion: all compulsory core profile operations: GetCapabilities, GetObserva- 
tion (O&M 2.0 encoding), DescribeSensor (SensorML encoding) and op- 
tional GetFeatureOfl nterest. Service performance can be tested using a 
generic client, available at: http://v-swe.uni-muenster.de:8080/WeatherSOS 
(accessed on 09.16.2012). 

The architecture of this solution is shown in Figure 3. There are three dis- 
tinguishable layers in it: network, business logic and data layer. Theservlet 
in the network layer is responsible for handling the HTTP based communi- 
cation. It transfers received requests to the business logic layer. The central 
part of the business logic layer is the RequestOperator. Each request deliv- 
ered to the RequestOperator is validated and, if successful, is forwarded to 
theOperationListener. Each operation is handled by an appropriate listen- 
er. All listeners share the same common interface. The configuration of the 
system is done through files. The procedure for service setup consists of 
three steps: i) implementation of theOperationListener, ii) implementation 
of theDAO (Data access object) for access to the data layer, iii) registration 
of the listeners configuration file. The SOS 52°North by default uses a Post- 



GIS database for data storage. In this database several tables have to be 
created (18 tables in total) assisted with relevant data types. 
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Figure 3. Architecture of SOS 52°North (Kunsteretal., 2012) 



3.3. Solution proposed 

To gain the most from the APRS network, an autonomous, universal telem- 
etry stations were planned to be build. This decision was motivated by the 
experiences from the flood in May 2010 in Poland, during which the need to 
monitor areas at risk of flooding and already flooded emerged. The hams 
(licensed operators of amateur radio stations) associated in the Lower Sile- 
sia Amateur Emergency Network actively collaborated, among others, with 
the Lower Silesian Center for Crisis Management. They monitored the sta- 
tus of rivers, verified information about floods given in the media, or pro- 
vided additional communication channelsin cases where the most common 
communication channels failed. It was observed that the use of automated 
telemetry stations, such as water level monitoring devices, reporting differ- 
ence in levels before and after the bridge, would greatly facilitate the tasks 
posed in front of radio amateurs. This is especially important at night and 
in low-urbanized areas with no roads or foot paths. Thus for the construc- 
tion of device mentioned thefollowi ng assumptions were made: 



• Modularity - the individual components of the system should be struc- 
tured in a way all owing their use in various projects, communication be- 
tween modules should be based on generally accepted standards; 

• Availability - the system should be built from readily available compo- 
nents, including microcontrollers that do not require complex pro- 
grammi ng systems; 

• Openness - the solution should be vendor free, thus no specific manu- 
facturers or models of equipment were suggested, the development of 
software parts shoul d f ol I ow the i dea of open-source. 

I n addition, the device of the system should assure capturing weather data 
from the APRS IS network and making them available on the Web via the 
SOS. The idea was to create a software bridging between the APRS network 
and the SOS service, which would allow to share information on current 
meteorological conditions based on readings of APRS weather stations. 

As already mentioned, I Gate stations transmit APRS frames from the radio 
network into I nternet. These frames are propagated between the APRS IS 
servers and can be captured by client software that supports the APRS I S 
specif i c protocol . The transmi ssi on of frames from the network to the APRS 
IS radio network is also possible. However, for practical reasons (high traf- 
fic generated in the radio network) this case is used very uncommon. Figure 
4 shows the scheme of the APRS network communi cati on . 




Figure 4. The scheme of APRS communication. 



4. Prototype Serving Data from Weather Station 



4.1. TNC 

To make use of the APRS network some devices are needed. One is a TNC 
(Terminal Node Controller). This device is attached to the transceiver, usu- 
ally combining a modem and a tracker (that uses GPS for current position 
acquisition and reporting). Sometimes is attached to the digital repeaters or 
telemetry stations (including weather stations). The KISS-modem (KISS- 
TNC) is a specific type of a TNC device. It acts as a modem (with modula- 
tion/demodulation of audio signals), controls data integrity (validates 
frame format and calculates checksums), and then outputs correct frames 
through the serial port. The name KISS-modem refers to Keep It Simple 
Stupid, and at the same time is a protocol definition that is used in the 
transmission of APRS frames via a serial link. 

At the current stage prototypes of two components have been built - a mo- 
dem and an APRS protocol analyzer. Both devices are based on ATmega 
microcontroller family. The software for the microcontrollers is written in 
thelanguageC and compiled with theavr-gcc compiler . 

4.2. KISS-modem 

Due to the unavailability of specialized integrated circuits used in the de- 
sign of modems and TNC devices working in the APRS network, it was nec- 
essary to develop an alternative solution. The common approachis to use a 
DSP (digital signal processor) and a microcontroller. Thus the KISS-TNC 
modem was build based on the ATmega328 microcontroller according to 
the proposal of Robert Marshall KI4MCW. This microcontroller serves 
many applications, including the Arduino runtime environment (see 
https://sites.google.com/site/ki4mcw/Home/arduino-tnc). The demodulation 
of an audio signal was carried out using the microcontroller's A/D convert- 
er. The modulation was done by applying a simple, four-bits D/A converter. 
For digital communication the serial port of the microcontroller was used. 

The modem created is a stand-alone unit that can be connected to a PC via 
communication interface (a serial TTL port adjusted to the requirements of 
RS-232C standard or USB converter). It was built with the use of existing 
software allowing fast implementation of the functionality of an APRS net- 
work node (digital repeater, telemetry station, tracker). The prototype was 
assembled on an expansion board attached to the base Arduino board. 

4.3. APRS protocol analyzer 

The weather stations of the APRS network send information using the 
AX.25 protocol (WA Beech et al., 1998). The description of the data encod- 



ing can be found at http://www.aprs.pl/wxparam.htm. This encoding involve 
frames with fixed positions defined for data values. The parameters in the 
weather data frame are integers, whereby substituting missing numbers 
with zeros is acceptable (for example, the pressure is stored in five digits 
and represents tenths of a millibar (hPa/10). 

To verify the content of the APRS protocol frames while testing the KISS 
modem functions, an analyzer was designed. It was assumed that an AT- 
mega 1280 or 2560 microcontroller will be used for the purpose (resources 
offered by these devices assure an execution of the tests planned). I n addi- 
tion, an Arduino Mega development kit (available with the AT mega 1280 
microcontroller) has been utilized. 

4.4. Integration with SOS 

I n the scope of the research descri bed a cl i ent of APRS I S servi ces was i m- 
plemented. It receives an unfiltered stream of APRS frames and extracts 
these frames, that include weather data. The frames are decoded, and then 
the parameters provided by a weather station are extracted, such as: the 
name (call sign and SSID), the last reported position, a timestamp of the 
last frame (if the frame rate does not include the time it gives a local time 
frame reception), meteorological parameters (temperature, humidity, wind 
speed and direction, rainfall information). In case of data mismatch (when 
an identified station instead of weather data transmits other data, eg. sta- 
tion metadata or additional comments) this information is also collected. 
Data already collected can be removed from a screen and saved in a chosen 
file on an ongoing basis. I n the next development step this program will be 
integrated with the descri bed implementation of SOS services. 



5. Summary 

This paper describes the standards and solutions used in wireless commu- 
nication (in a mobile network and amateur radio network). It discuss to 
idea of integration of SWE, LBS and APRS through Web service implemen- 
tation. The experiments and prototype implementation was done for a sys- 
tem offering sensor reading and localization data (from the APRS network 
or mobile devices) through a SOS interface. In a running example, weather 
station measurements were served and processed. The results received 
proved that assumptions highlighted are implementable and the devices 
designed can be used in many practical use cases. 
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